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Abstract 

Commanders  require  relevant  information  about  background  information  in  order  to  exercise  effective  command  and  control 
(C2).  METT-TC  factors  (Mission,  Enemy,  Terrain  &  Weather,  Troops,  Time  Available  and  Civil  Considerations)  represent 
the  canonical,  militarily  significant  background  against  which  information  is  evaluated  and  military  decisions  are  made.  If 
this  background  is  to  be  encoded,  shared,  and,  ultimately,  processed  and  reasoned  about  by  computers  or  computer-assisted 
C2  systems,  the  METT-TC  background  must  be  represented  in  some  standard  format  with  a  shared  computer-processable 
semantics.  The  JC3IEDM  (Joint  Command,  Control,  and  Consultation  Information  Exchange  Data  Model)  represents  several 
years  of  effort  by  NATO’s  Multinational  Interoperability  Programme  at  developing  a  representation  of  military  situations  in 
order  to  support  communication  and  interoperability  among  NATO  forces.  All  information  to  be  shared  by  participants  must, 
therefore,  be  representable  within  JC3IEDM.  In  this  paper,  we  point  out  aspects  of  METT-TC  that  are  not  currently  or  not 
completely  representable  in  JC3IEDM.  These  include  aspects  such  as  cover  and  concealment,  fields  of  fire,  and  mission 
purpose.  We  end  by  suggesting  ways  in  which  JC3IEDM  can  be  extended  to  represent  these  aspects  of  METT-TC  factors. 

1.  Introduction:  METT-TC  Factors  and  Representability 

Commanders  require  accurate,  relevant,  and  timely  information  about  the  background  factors  at  play  on  the  battlefield,  the 
so-called  METT-TC  factors  (Mission,  Enemy,  Terrain  &  Weather,  Troops,  Time  Available  and  Civilian  Considerations),  in 
order  to  make  command  and  control  decisions.  If  this  background  information  is  to  be  encoded,  shared,  and,  ultimately, 
processed  and  reasoned  about  by  computers  or  computer-assisted  C2  systems,  the  METT-TC  background  must  be 
represented  in  some  standard  format  with  a  shared  computer-processable  semantics.  Currently,  the  most  widely  adopted 
representation  for  sharing  military  information  is  the  information  exchange  data  model  promulgated  by  the  Multilateral 
Interoperability  Programme  of  NATO,  with  participation  by  26  countries.  The  standard  is  currently  being  used  by  several 
elements  of  the  Department  of  Defense,  coalition  forces  and  commercial  organizations.  The  US  Marine  Corps  recently 
adopted  JC3IEDM  as  a  standard  for  data  integration,  for  example  [Allen,  2006]. 

METT-TC  factors  are  descriptions  of  militarily  relevant  aspects  of  the  environment  or  background  upon  which  a  military 
operation  occurs.  The  accurate  depiction  of  the  environment  in  which  military  action  occurs  is  necessary  for  good  decision¬ 
making.  Further,  background  information  often  informs  how  incoming  data  is  to  be  interpreted.  The  military  commander’s 
view  of  the  state  of  the  battlespace  is  constructed  from  reports  generated  by  both  human  and  non-human  sensors  in  the 
battlespace.  In  many  cases  (see  for  example  the  discussion  in  [Powell  et  al,  2006]),  the  import  or  credibility  of  what  is  being 
communicated  by  these  reports  is  determined  by  the  background  information.  Therefore,  unless  background  conditions  are 
accurately  described,  an  accurate  depiction  of  what  is  currently  going  on  in  the  battlespace  is  not  possible.  As  such, 
background  information  is  not  simply  ancillary  information  in  a  military  environment. 

We  employ  the  notion  of  ‘background  information’  rather  than  ‘context’  here  since  the  notion  of  context  in  information 
systems  often  involves  a  sense  of  un-shared  perspective  that  we  want  to  avoid  [Stalnaker,  1999].  In  context-aware 
representations,  statements  that  are  true  in  one  context  are  not  true  in  another  (the  house  is  to  the  left  of  the  barn  from  the 
perspective  of  x  but  not  of  y)  but  may  be  translatable  into  true  statements  in  another  perspective  (“the  bam  is  to  the  right  of 
the  house”).  Similarly,  within  the  context  of  the  Sherlock  Holmes  stories,  “Holmes  lived  on  Baker  Street  in  London”  is  true, 
but  that  is  not  true  within  the  context  of  an  official  London  census  of  the  time.  There  is  no  information  about  the  background 
or  environment  that  cannot  be  shared  with  respect  to  METT-TC  factors  or  which  requires  translation  in  order  to  be  true  for 
different  users.  (Translation  may  of  course  be  required  to  make  the  information  usable  by  those  with  different  linguistic 
backgrounds.)  Background  information  can  (and  does)  influence  what  can  be  inferred  from  a  statement,  however.  With  the 
background  information  “There  is  a  severe  backup  on  US  Route  93  on  the  southbound  lanes  at  Medford,  MA”,  it  can  be 
inferred  that  the  travel  time  from  Winchester,  MA  to  Boston’s  airport  will  take  longer  than  the  average  travel  time  that  could 
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be  predicted  using  the  distance  between  the  two  points  and  the  average  speed  of  vehicles  on  Route  93  for  that  interval,  for 
example.  However,  the  fact  encoded  as  background  knowledge  (“There  is  a  backup  on  Route  93  south  at  time  t”)  is  true  for 
all  users. 

In  the  rest  of  this  paper,  we  examine  to  what  extent  all  of  the  relevant  aspects  of  background  or  environment  of  military 
operations  can  be  represented  within  the  framework  of  the  JC3IEDM  information  exchange  model. 

2.  Semantic  Interoperability:  JC3IEDM  and  Related  Work 

The  Multilateral  Interoperability  Programme1  (MIP)  is  a  long-standing,  NATO-supported  program  intended  to  foster 
international  interoperability  of  Command  and  Control  Information  Systems  (C2IS)  through  the  development  of  standard 
data  models  and  data  exchange  mechanisms.  Significant  joint  coalition  effort  has  gone  into  the  development  of  the  MIP  data 
model,  which  was  first  released  in  the  mid  to  late  1990’s  as  the  Generic  Hub  (GH)  Data  Model.  In  subsequent  years  it 
became  known  as  the  Land  Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM),  followed  by  the 
Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  and  now  it  exists  as  the  Joint  Command,  Control  and 
Consultation  Information  Exchange  Data  Model  (JC3IEDM).  The  data  model  captures  information  about  an  impressive 
array  of  battlespace  objects  and  features,  their  properties,  and  situations  made  up  of  facts  about  objects  and  activities 
involving  collections  of  objects. 

JC3IEDM,  first  published  by  the  MIP  in  December,  20052,  aims  at  encoding  all  of  the  relevant  information  about  an  arena  of 
operations  that  commanders  would  need  to  share.  As  such,  it  is  a  very  detailed  and  comprehensive  data  model.  JC3IEDM 
allows  the  representation  of  the  land,  sea,  and  air  as  well  as  certain  aspects  of  the  communications  infrastructure.  It 
represents  nearly  all  objects  of  interest  including  organizations,  persons,  equipment,  facilities,  geographic  features,  weather, 
capabilities,  and  military  control  measure  such  as  boundaries.  On  the  face  of  it,  this  model  offers  broad  coverage  of  METT- 
TC  factors.  An  updated  version  3.1  was  published  in  December,  2006. 

While  JC3IEDM  is  intended  foremost  for  the  exchange  of  command,  control  and  communication  information  between 
information  systems,  it  is  increasingly  gaining  consideration  as  the  basis  for  the  general  data  models  that  underlie  C3 
information  systems.  A  primary  reason  for  this  trend  is  the  desire  to  leverage  the  great  wealth  of  experience  and  knowledge 
that  has  gone  into  its  development.  JC3IEDM  consists  of  289  entities,  396  relationships  between  entities,  1729  entity 
attributes  and  nearly  7000  value  codes.  The  MIP  data  model  is  updated  on  a  regular  (one  might  say  “aggressive”)  basis.3 
Several  projects  currently  envision  using  JC3IEDM  as  the  basis  for  automatically  encoding  and  exchanging  battlespace 
information.  The  German  Sokrates 4  project,  for  example,  is  developing  an  automatic  battlespace  report  analysis  tool  that 
uses  a  Protege-encoded  ontology  based  on  C2IEDM  to  process  reports  and  generate  information  to  be  added  to  both  a 
database  and  to  a  map  interface  which  represents  the  common  operational  picture.  The  Battlefield  Management  Language 
research  program  (BML,  see  below)  and  other  project  teams  make  a  strong  case  for  using  the  C2/JC3IEDM  as  a  basis  for 
ontologies  for  battlespace  management 

The  upper-level  entities  in  JC3IEDM  are  related  according  to  the  diagram  in  Figure  1.  (In  IDEFIX  notation,  the  closed  dot 
indicates  that  there  may  be  many  such  entities  in  the  relationship.  An  open  dot  means  just  one.) 


1http://www.  mip-site.org 

2  http://mip-site.org/publicsite/Baseline  3.0/ 

3  We  have  made  a  translation  of  JC3IEDM  into  an  OWL  ontology  freely  available  for  others  to  use 
(http://vistology.eom/ont/2006/JC3IEDM3.0).  The  translation  was  performed  using  the  XML  document  that  specifies  the 
JC3IEDM  3.0  ERwin  data  model  definition;  due  to  the  use  of  this  XSD-defined  document,  other  ERwin  based  data  models 
can  be  translated  into  OWL  using  a  similar  strategy  (and  in  many  cases,  the  code)  that  we  have  described  elsewhere  [Matheus 
and  Ulicny,  2006]. 

4  SOKRATES  -  Automatic  Report  Analysis  project  page,  http://www.fgan.de/fkie/fkie  c41  f!3  en.html 
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Figure  2.  Independent  Entities  for  Creating  the  Data  Specification 

Figure  1.  Independent  Entities  for  Creating  the  Data  Specification 

Figure  1  shows  all  of  independent  entities  found  at  the  highest  level  of  the  JC3IEDM  along  with  the  conceptual  relationships 
between  them;  these  relationships  represent  conceptual  aggregates  of  finer  relationships  and  additional  entities  found  in  the 
logical  model.  Some  things  to  note: 

1)  Most  of  these  Entities  are  sub-classed  in  the  logical  model  and  in  some  cases  the  hierarchy  of  classes  can  be 

relatively  deep  (i.e.,  greater  than  3). 


There  are  two  object  classes,  OBJECT-TYPE  and  OBJECT-ITEM.  OBJECT-TYPE  is  used  for  more  static 
information  associated  with  an  entire  class  of  objects  (e.g.,  the  track  width  of  an  Abrams  Tank,  its  maximum  speed, 
etc.)  where  as  OBJECT-ITEM  is  used  to  capture  information  specific  to  individuals  (e.g.,  the  speed  of  a  tank,  the  fact 
it  has  5  gallons  of  gas).  The  original  intended  use  of  JC3IEDM  and  its  precursors  provide  an  explanation  of  this. 
JC3IEDM  was  intended  to  be  a  stable  data  model,  the  stability  of  which  was  guaranteed  by  its  extensibility.  For  this 
reason,  the  designers  chose  a  parallel  hierarchy  of  types  and  instances  of  objects  so  that  if  a  new  type  of  tank  was 
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introduced,  for  example,  representing  this  fact  would  require  simply  adding  another  row  to  the  EQUIPMENT-TYPE 
table  and  a  row  for  each  instance  of  a  tank  of  that  type  to  the  OBJECT-ITEM  tables.  It  would  not  require  a  new 
schema.  The  OBJECT-TYPE  and  OBJECT-ITEM  hierarchies  do  not  fully  mirror  each  other,  particularly  deeper 
within  the  structures,  but  they  are  closely  related  (see  Figure  2  below). 

3)  REPORTING-DATA  represents  pedigree  information  that  is  used  extensively  to  identify  when,  from  whom  and  how 
reliable/credible  a  specific  piece  of  information  is. 

Significantly,  there  is  an  open-source  XML  Schema  conversion  tool  that  allows  one  to  convert  the  published  data  model  into 
an  XML  Schema  at  a  variety  of  levels.  One  level  is  essentially  just  the  serialization  of  the  physical  data  representation  in 
relational  tables.  There  are  then  two  flavors  of  Object-Oriented  (OO)  XML  Schemata  (XSD)  conversions  possible  that  allow 
for  the  representation  of  discrete  battlespace  facts  with  more  or  fewer  constraints  on  the  relations  between  items  specified 
within  the  schemata  itself.  That  is,  one  OO  XML  Schema  allows  essentially  unconstrained  associations  between  entities;  the 
other  provides  ontology-based  constraints  on  associations.  The  various  schemata  are  described  in  ANNEX  O. 
EXTEN SIBLMARKUP  LANGUAGE  (XML)  REFERENCE  IMPLEMENTATIONS  of  the  published  standard.5 

For  our  purposes,  we  have  found  it  useful  to  represent  messages  in  the  format  of  OWL  or  RDF  triples:  subject-predicate- 
object,  abstracting  away  from  the  use  of  true  URIs  as  proxies  for  referents.  This  allows  us  to  envision  a  future  set  of 
applications  in  which  information  about  the  battlespace  would  be  reasoned  about  automatically  within  a  logical 
representation  derived  from  something  like  JC3IEDM  or  a  successor  representation  rather  than  simply  using  JC3IEDM  to 
enable  sharing  of  a  representation  of  the  battlespace.  The  conversion  of  such  a  large  and  rich  data  model  into  a  logical 
representation  like  OWL  is  a  daunting  task,  but  we  have  shown  that  it  can  be  entirely  done  in  an  automated  way  [Matheus 
and  Ulicny,  2006]. 

Unfortunately,  because  of  the  parallel  OBJECT/OBJECT-TYPE  hierarchies,  in  a  direct  translation  to  OWL  from  the 
JC3IEDM  data  model,  this  means  that  the  directly  translated  OWL  does  not  represent  that  a  tank  instance  inherits  the 
properties  defined  for  that  tank  type  directly.  There  is  a  type  hierarchy  and  an  instance  hierarchy  and  they  are  connected  by 
an  entity  of  OBJECT-ITEM-TYPE.  This  makes  such  simple  inferences  impossible  from  within  the  context  of  OWL  alone, 
given  our  current  translation  of  JC3IEDM  into  OWL.  Two  possible  solutions  exist  here:  either  rules  can  be  provided  that 
allow  one  to  make  such  inferences  on  the  basis  of  the  automatically-translated  OWL,  or  one  could  translate  the  JC3IEDM 
into  OWL  in  a  way  that  represents  the  semantics  of  the  JC3IEDM  model  more  transparently,  perhaps  taking  the  set  of 
relations  from  the  CIDOC-CRM  model  to  relate  JC3IEDM  models  in  a  more  direct  way.  We  make  note  of  this  difficulty 
here,  although  it  does  not  play  a  central  role  in  the  discussion  that  follows. 


5  http://www.mip-site.org/publicsite/Baseline  3.0/JC3IEDM-Joint  C3  Information  Exchange  Data  Model/JC3IEDM- 

Annex%20Q-XML-UK-DM W G-Edition  3.0  2005-12-Q9.pdf 

VIStology,  Inc. 


1-098 


4 


12th  ICCRTS 


Figure  2  Conceptual  relationship  between  OBJECT-TYPE  and  OBJECT-ITEM  Entities 


2.1.  Related  Initiatives  and  Research  Programs 

The  Battlefield  Management  Language  (BML)  [Tolk  et  al,  2005]  is  a  research  program  aimed  at  developing  a  collection  of 
web-based  services  that  is  based  on  C2IEDM,  a  previous  version  of  the  JC3IEDM.  BML  is  described  as  “an  unambiguous 
language  to  command  and  control  forces  and  equipment  conducting  military  operations  and  to  provide  for  situational 
awareness  and  a  shared,  common  operational  picture”.  The  first  version  of  the  CBML  standard  is  available  here 
fhttp://www.sisostds.org/index.php?tg=fileman&idx=list&id=33&gr=Y&path=CBML+Standard+Version+f).  It  is  basically 
an  extension  of  a  subset  of  the  C2IEDM  model  pertaining  to  actions  and  their  participants  necessary  to  capture  military  tasks. 

The  Mobility  Common  Operational  Picture  (M-COP)  [Blais,  2005]  defines  architecture  for  web-based  tools  supporting 
battlespace  operations.  They  discuss  the  need  for  an  M-COP  ontology  which  they  expect  to  be  built  by  importing  ontologies 
from  other  groups,  but  have  not  yet  announced  further  progress.  M-COP  is  described  as  “A  subset  of  the  COP  consisting  of 
relevant  tactical  movement  and  maneuver  data  and  information  shared  by  more  than  one  command.  The  M-COP  can  be 
tailored  for  various  users  and  includes  data  and  information  for  mobility  of  individual  combatants,  ground  vehicles,  and 
autonomous/robotic  vehicles.” 

A  related  initiative  is  the  development  of  GeoBML  [Stein,  2005]  described  as  a  system  to  “enable  tactical  terrain  reasoning 
services  for  the  range  of  BC  systems  and  users  that  will  match  the  level  of  abstraction  with  needs  of  BC  as  instantiated  in  the 
C2IEDM.”  GeoBML  will  allow  a  “deeper-level  of  automated  decision  support  to  human  and  software  users  incorporating 
the  dynamic  environment.”  GeoBML  is  a  research  project  that  is  part  of  the  Battlespace  Terrain  Reasoning  and  Awareness6 
(BTRA)  initiative  of  the  Army  Corps  of  Engineers. 

The  Military  Scenario  Definition  Language  (MSDL)  [Franchesini  et  al,  2004]  is  being  developed  by  the  OneSAF  Objective 
System  (OOS)  to  provide  simulations  with  a  mechanism  for  loading  Military  Scenarios.  As  a  standard,  MSDL  is  not  being 
developed  for  simulation  alone.  The  intent  is  for  MSDL  to  define  Military  Scenarios  that  are  independent  of  the  application 
of  that  scenario.  To  that  end,  MSDL  is  an  XML-based  data  interchange  format  that  enables  C2  planning  applications  to 
interchange  the  military  portions  of  scenarios  with  Simulations  and  other  applications.  The  scope  of  MSDL  is  bounded  by 
the  situation  at  one  instant  in  time  combined  with  the  COA  about  to  be  taken  in  context  to  that  situation.  The  intent  is  for 
MSDL  to  include  that  infonnation  which  is  either  Core  or  Common  to  the  situation  and  course  of  action  of  a  military 
scenario. 


6  www.tec.army.mil/fact  sheet/BTRA.pdf.  One  product  of  the  BTRA  initiative  is  the  FAS  ST  (Fast  All-season  Soil 
STrength)  model  that  allows  modelers  to  predict  the  effects  of  weather  on  terrain  for  trafficability. 
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3.  Representing  Mission  in  JC3IEDM 

Mission  characterizes  a  planned  military  operation  within  a  specified  period  of  time  and  with  specific  objectives.  The  Mission 
includes  the  Who,  What,  When,  Where  and  Why  of  an  ordered  military  action.  Representation  of  the  mission  includes 
identifying  the  objective  and  specifying  the  essential  and  non-essential  tasks  of  the  operation.  The  Mission  includes  one  or 
more  tasks  (What)  and  any  constraints  applicable  in  achieving  those  tasks  (Rules  of  Engagement).  Areas  of  interest  (Where) 
for  the  mission  are  identified  here.  The  When  is  specified  as  the  time  available  for  acting  from  a  given  start  time.  The 
overall  purpose  of  the  mission  (Why)  is  specified. 

In  JC3IEDM,  there  is  no  entity  that  corresponds  to  a  mission  as  a  distinct  entity  over  and  above  the  tasks  it  comprises.  A 
mission  would  therefore  have  be  encoded  as  a  set  of  ORDERED  ACTION-TASKs  with  corresponding  OBJECTIVES  and 
RULES-OF-ENGAGEMENT  with  allotted  start  and  end  times.  Named  areas  of  interest  are  represented  as  a  category  of 
CONTROL-FEATURE. 

RULES-OF-ENGAGEMENT  are  represented  as  text  strings.  The  “why”  of  the  mission  is  also  only  representable  in  terms 
of  the  intent-text  associated  with  the  ORGANISATION-ASSOCIATION,  which  specifies  why  a  unit  or  other  entity  (“who”) 
is  involved  in  the  activity  in  the  form  of  a  text  string.  Unless  these  text  strings  are  further  decomposed  into  a  logical 
representation,  it  would  be  impossible  to  reason  about  them  automatically. 

For  example,  to  encode  the  following  mission: 

The  1st  Unit  of  Employment  (who)  in  the  next  24  hours  (when)  is  ordered  to  deploy  to  Atropia  (where)  to  conduct  an 
NEO  of  US  personnel  (what)  in  order  to  prepare  for  an  invasion  of  Atropia. 

Example  1:  Representation  of  MISSION  in  JC3IEDM 


<OWL> 

<ACT I ON- TASK- ORDER  rdf : ID="ACT1 "> 

<name-text  rdf : type="xsd : string">Atropia  NEO</name-text> 

<is-f ocused-on> 

<Ob j  ectiveList> 

<OID>AOIl</OID> 

<!--  The  specific  value  that  represents  the  class  of  ACTION-OBJECTIVE  with 
respect  to  item  or  type.  --> 

< ! —  A  class  of  battlespace  object  (FACILITY-TYPE,  FEATURE-TYPE,  MATERIEL-TYPE, 
ORGANISATION-TYPE  or  PERSON-TYPE)  which  is  the  focus  of  a  specific  ACTION.  — > 
<category-code>OT</ category- code> 

<qualif ier-code>AUTH</ qualif ier-code> 

<priority-code>l</priority-code> 

<OB JECT- ITEM-TYPE> 

<ob j ect-type-id  rdf : resource="OT16"/> 

<OB JECT- ITEM- TYPE> 

</Ob j  ectiveList> 

</ is-f ocused-on> 

<!--  Noncombatant  Evacuation  Operation  --> 

<activity-code  rdf : type="xsd : string">EVACT</ activity-code> 

<!--  action  to  take  place  over  next  24  hours  --> 

<planned-start-datetime>20100801120000 . 0 0 0< /planned- start -date time> 
<planned-end-datetime>20100802120000 . 000</planned-end-datetime> 
<is-acted-upon-as- specif ied-by> 

<ORGANIZAT ION-ACT ION-ASSOCI AT ION-Controls> 

<has-its-role-specif ied-through  rdf : resource="OI57"/>  <!--  =  1UE  --> 

<ef fective-datetime>20100801120000 . 000</ ef fective-datetime> 

< in tent- text > 

The  1st  Unit  of  Employment  (UE)  deploys  to  conduct  the  NEO  with  three 
subordinate  Units  of  Action  (UA) 

</ intent-text> 
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</ ORGANIZATION-ACTION-ASSOCIATION-Controls> 

</ is-acted-upon-as- specif ied-by> 

<is-geometrically-def ined-through> 

<LOCATION  rdf : resource="ATROPIA"/> 

</ is -geometrical ly-def ined-through> 

<requires> 

<ACTION-RESOURCE-ITEM> 

<ob j  ect-item-id  rdf : resource="Al . 3" /> 

</ACTION-RESOURCE-ITEM> 

</ requires> 

</ACTION-TASK-ORDER> 

<UNIT  rdf : ID="OI57"> 

<name-text>lst  Unit  of  Employment</name-text> 

<is-classif ied-as> 

<0B JECT- ITEM-TYPE> 

<ob j ect-type-id  rdf : resource="OT57"/> 

<is-ref erenced-to  rdf : resource="RPTDl"/> 

</ OBJECT- I TEM-TYPE> 

</ is-classif ied-as> 

< formal - abbreviated- name -text > 

1st  Unit  of  Employment 
</ f ormal-abbreviated-name-text> 

</UNIT> 

<UN IT -TYPE -Combat  rdf : ID="OT57 "> 

< dummy- indicator- code  rdf : type="xsd : string">NO</ dummy- indi cat or- code> 
<name-text  rdf : type="xsd : string">Inf  Division</name-text> 

<command- function- indi cat or- code  rdf : type="xsd : string">YES</ command- functi on- 
indicat  or-  code> 

< service -code  rdf : type="xsd : string ">ARMY</ service-code> 
<arm-category-code>INF</ armc-ategory-code> 

<size-code>DIV</ size-code> 

</UNIT-TYPE-Combat> 

<FACILITY  rdf : ID="0I15"> 

<name-text>Atropia</ name-text> 

<is-classif ied-as> 

<0B JECT- ITEM- TYPE> 

<ob j ect-type-id  rdf : resource="0T15" /> 

<is-referenced-to  rdf : resource="RPTDl"/> 

</ OBJECT- I TEM-TYPE> 

</ is-classif ied-as> 

<i s -geometrical ly-def ined-through> 

<!--  location  of  city  is  location  of  action,  not  otherwise  defined  --> 
<LOCATION  rdf : ID="ATROPIA"/> 

</ i s -geometrical ly-def ined-through> 

</FACILITY> 

<FACILITY-TYPE-City  rdf : ID="0T15"/> 

< PERSON- TYPE  rdf : id="OTl 6"> 

<person-type-category-code>CIV</person-type-category-code> 

<person-type-subcategory-code>NKN</person-type-subcategory-code> 

<has> 

<!--  A  specification  of  a  country  or  political  entity  to  which  membership  or 
allegiance  may  be  ascribed.  --> 

<AFFILIATION-GEOPOLITICAL  rdf : id="USA"> 

<af f iliation-geopolitical-code>USA</ af f iliation-geopolitical-code> 
</AFFILIATION-GEOPOLITICAL> 

</has> 

</ PERSON- TYPE> 
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<!--  just  a  dummy  reporting  data  for  all  objectitems  --> 

<RE PORT ING-DATA-ABSOLUTE- TIMING  rdf : ID="RPTD1 "> 
<credibility-code>RPTFCT</ credibility-code> 

<reporting-datetime>2 01 00 8 10030000 . 000</ report ing-datetime> 
<reporting- organisation -id  rdf : resource="OI57"/> 

</ RE PORTING- DATA- ABSOLUTE -TIMING> 

</ OWL> 


It  is  possible  to  group  several  action-tasks  together  via  a  context  element,  but  it  is  not  possible  to  assign  an  objective  to  the 
context  as  a  whole.  Thus,  while  it  is  possible  to  assign  an  objective  or  purpose  to  the  component  tasks  of  a  mission,  it  is  not 
possible  to  assign  an  objective  or  purpose  to  the  set  of  action-tasks  taken  together.  This  is  analogous  to  being  able  to  say  that 
one  boiled  the  noodles  and  heated  the  sauce  in  order  to  cook  the  spaghetti  but  not  be  able  to  say  why  one  cooked  the  spaghetti 
(e.g.  to  provide  dinner  for  the  family). 

JC3IEDM  lacks  some  vocabulary  that  might  be  useful  as  well.  The  Military  Scenario  Definition  Language  (MSDL)  group7, 
for  example,  employs  the  entire  Army  Universal  Task  List  for  its  set  of  possible  tasks.  These  include  some  activities  such  as 
“raid”  that  are  not  included  in  the  JC3IEDM  3.0.  The  MSDL  also  allows  the  specification  of  triggering  events  for  activities  - 
—  friendly  events,  enemy  events,  threat  events,  or  movement  events  —  which  are  not  possible  in  JC3IEDM  representations  of 
tasks.  Decision  points  and  triggering  events  are  not  explicitly  representable  in  JC3IEDM. 

4.  Enemy 

The  METT-TC  representation  of  the  Enemy  must  be  able  to  represent  a  complete  assessment  of  the  enemy's  strength, 
including  weapons  and  weapons  range,  composition  and  order  of  battle,  boundaries  between  units  and  reinforcement 
potential,  readiness  for  battle,  location  and  mobility.  Enemy  doctrine  has  likely  been  assessed  ahead  of  time  and  is  available 
as  mission  background  information.  The  analysis  of  the  enemy  —  in  the  context  of  other  METT-TC  factors  such  as 
terrain/weather  and  blue  troops  —  identifies  possible  avenues  of  approach  and  enemy  courses  of  action. 

An  important  aspect  of  the  representation  of  the  enemy  is  the  representation  of  historical  patterns  of  enemy  activity  even 
when  those  haven’t  been  canonicalized  as  doctrines.  For  example,  it  would  be  important  to  aggregate  the  enemy’s  placing  of 
IEDs  along  routes  over  time,  by  day  of  week  and  time  of  day,  to  facilitate  route  planning. 

JC3IEDM  is  designed  to  allow  a  common  representational  format  for  enemy  and  friendly  troops.  The  only  difference  is  the 
ObjectltemStatusHostilityCode,  which  is  HO  for  Hostiles,  FR  for  Friendlys,  and  so  on  for  other  statuses  of  forces  (e.g. 
suspect,  neutral,  unknown,  etc.).  Enemy  actions  are  expressed  in  the  same  way  as  friendly  Actions. 

Weapons  can  be  associated  with  forces  at  various  structural  levels.  However,  it  is  not  possible  to  relate  weapons  with  their 
ranges  within  JC3IEDM.  Thus,  it  is  not  possible  to  represent  or  derive  a  field  of  fire  from  the  location  of  enemy  forces  and 
the  association  of  particular  weapons  with  those  forces. 

Enemy  courses  of  action  (ECOAs)  are  not  representable  except  as  planned  enemy  action-tasks.  This  is  obviously  a 
deficiency,  since  ECOAs  should  be  represented  as  possible,  not  future,  actions.  In  general,  there  is  no  way  to  represent 
logical  modalities  (possible/necessary,  should/must)  within  JC3IEDM  or  within  a  straightforward  transformation  of 
JC3IEDM  to  a  logical  representation  such  as  OWL.  JC3IEDM’s  only  concession  to  modality  is  the  notion  of  CAPABILITY, 
which  encodes  the  abilities  of  individual  OBJECT-ITEMs  and  -TYPEs.  Thus,  one  can  say  that  this  particular  object  can  do 
certain  things,  but  one  cannot  represent  that  an  event,  situation  or  fact  involving  certain  OBJECTS  might  happen,  is  likely  to 
occur,  cannot  occur  and  so  on. 

Similarly,  the  representation  of  enemy  doctrine  (usually  or  normally  such-and-such  unit  or  unit  type  does  x  in  a  certain 
situation)  within  JC3IEDM  again  requires  a  notion  of  logical  modality  that  is  absent  from  JC3IEDM.  At  most,  one  could 
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represent  that  an  enemy  unit  had  done  actions  of  a  specified  type  at  certain  dates,  but  any  representation  of  a  norm  or 
behavior  is  not  possible. 

5.  Terrain  and  Weather 

It  must  be  possible  to  represent  complete  information  on  terrain  including  the  location  and  properties  of  natural  and  artificial 
terrain  features  such  as  mountains,  marshes,  cliffs,  and  so  on  as  well  as  cities,  airfields,  bridges,  railroads,  and  ports,  slope, 
elevation,  soil  conditions,  and  vegetation.  It  must  be  possible  to  represent  the  impact  of  these  on  vehicle  and  human 
movement  rates,  maintenance,  tempo,  trafficability,  and  maneuverability  by  various  types  of  forces,  as  well  as  the  impact  on 
the  ability  to  engage  in  combat.  The  five  military  aspects  of  terrain  are: 

o  Observation  and  fields  of  fire, 
o  Cover  and  Concealment 
o  Obstacles, 
o  Key  and  decisive  terrain, 
o  Avenues  of  approach. 

As  for  weather,  it  must  be  possible  to  represent  all  aspects  of  current  and  projected  weather  and  atmospheric  conditions  in  a 
location  as  well  as  to  record  the  effect  of  weather  on  terrain,  troops  and  equipment  as  necessary 

We  have  seen  from  the  Mission  that  built  environment  features  are  represented  in  JC3IEDM  as  Facilities.  Geographic 
features  are  represented  as  Feature(s).  Atmospheric  elements  are  represented  as  Meteorologic-Feature  ( s ) .  The 
following,  for  example,  shows  a  representation  of  a  segment  of  Interstate  5  in  San  Diego  within  JC3IEDM. 


<OWL> 

CROAD  rdf : I D= " ROAD 1 " > 

<name-text  rdf : type="xsd : string">INTERSTATE  5</name-text> 
<is-geometrically-def ined-by> 

CLINE  rdf : ID="LINE1"> 

<is-def ined-using> 

CLINEPOINTLI ST> 

Crdf : Seq> 

CLINEPOINT  rdf : ID="LP1"> 

< linepo in t- sequence -ordinal  rdf : type="xsd : string">lClinepoint-sequence- 
ordinal> 

<makes-reference-to> 

CCARTESIANPOINT  rdf : ID=" PT1 "> 

<cartesian-point-x-coordinate-dimension 

rdf : type="xsd: string "> 62 61 91 6 .50005901c/ cartes ian-po in t-x- coordinate -dimens ion> 
Ccar te s ian-po in t-y- coordinate -dimens ion 

rdf : type="xsd: string">1911741 . 87236069c/ cartes ian-po in t-y- coordinate -dimens ion> 
Ccartesian-point-z -coordinate -dimens ion 
rdf : type="xsd: string">0C/ cartesian-point-z-coordinate-dimension> 

C/CARTES IANPOINT> 

C /makes- re ference-to> 

C/LINEPOINT> 

CLINEPOINT  rdf : ID="LP2"> 

C linepo in t- sequence -ordinal  rdf : type="xsd : string ">2C linepo in t -sequence - 
ordinal> 

Cmakes-reference-to> 

CCARTESIANPOINT  rdf : ID=" PT2 "> 

Ccar tes ian-po in t-x- coordinate -dimens ion 

rdf : type="xsd: string">6261424 ,50005855c/ cartes ian-po in t-x- coordinate -dimens ion> 
Ccar tes ian-po in t-y- coordinate -dimens ion 

rdf : type="xsd: string">1912720 . 87216961c/ car tes ian-po in t-y- coordinate -dimens ion> 
Ccartesian-point-z -coordinate-dimens ion 
rdf : type="xsd: string">0C/ cartesian-point-z-coordinate-dimension> 

C /CARTES I ANPOINT> 

C /makes- re ference-to> 

C/LINEPOINT> 


VIStology’,  Inc. 


1-098 


9 


12th  ICCRTS 


CLINEPOINT  rdf : ID="LP3"> 
</ rdf : Seq> 
</LINEPOINTLIST> 

</ is-def ined-using> 

</LINE> 

</ is-geometrically-def ined-by> 
</ROAD> 

</ OWL> 


JC3IEDM  represents  Terrain  in  terms  of  Features  and  Facilities,  which  are  Object-Items  and  have  Object-Types,  which  have 
locations.  Unfortunately,  one  cannot  say  that  a  Facility  or  Feature  is  the  Location  of  an  Action,  only  that  the  Action  has  a 
geographically  specified  location  that  is  shared  with  a  Facility  (or  overlaps  with  part  of  a  facility).  One  can  also  use  a 
dummy  location  to  say  (indirectly)  that  two  facilities  are  co-located,  for  example  to  say  that  a  field  hospital  is  located  in  a 
church,  the  geolocation  of  which  is  not  itself  represented,  for  whatever  reason. 

JC3IEDM  represents  facilities  (man-made  features)  at  only  a  crude  level  of  detail.  One  can  only  say  that  one  of  a  prescribed 
set  of  JC3IEDM  features  is  present  at  a  location;  one  cannot  describe  it  further  according  to  sub-features.  These  can  only  be 
represented  as  features  that  happen  to  be  collocated.  To  give  another  example:  it  is  possible  to  specify  that  a  sniper,  for 
example,  has  a  location  that  is  the  location  of  a  particular  building,  but  it  is  not  possible  to  specify  that  the  sniper  is  located  at 
the  third  window  from  the  left  on  the  north  side  of  the  sixth  floor  of  that  building  (cf.  CityGML8). 

At  the  level  of  vocabulary,  the  Terrain  Common  Data  Model  specifies  more  feature-specific  parameters  for  describing  natural 
features  than  JC3IEDM  does.  There  are  approximately  167  features  in  the  TCDM  that  have  associated  descriptive 
parameters  as  opposed  to  the  twenty  or  so  features  in  JC3IEDM  which  have  set  parametric  descriptions. 

Weather  features  are  represented  in  terms  of  JC3IEDM  METEOROLOGIC-FEATURE,  which  are  also  OBJECT-ITEMs 
with  locations.  Other,  non-localized  aspects  of  weather  (Moon,  Sun,  Wind,  Nautical  Twilight,  Relative  Humidity,  Chance  of 
Precipitation,  General  Visibility,  Clouds,  Fog,  and  Haze)  do  not  really  have  specifiable  locations,  but  can  be  associated  with 
reports  from  a  given  location. 

Of  the  five  military  aspects  of  terrain  above,  it  is  possible  to  represent,  key  terrain,  and  avenues  of  approach,  but  not 
obstacles,  fields  of  fire  or  cover  and  concealment.  Being  an  obstacle  is  a  relative  notion:  x  is  an  obstacle  to  some  y.  Few 
things  are  obstacles  to  everything.  With  respect  to  fields  of  fire,  as  we  mentioned  above,  JC3IEDM  does  not  allow  for  the 
representation  of  weapon  ranges.  If  it  did,  fields  of  fire  could  be  represented  somewhat  accurately  as  geometric  areas  with 
specified  locations.  Not  all  of  the  inferences  one  would  like  to  draw  from  the  current  METT-TC  conditions  are  purely 
symbolic  or  logical  inferences.  Some  inferences  could  involve  numeric  computations.  The  Army’s  Battlespace  Terrain 
Reasoning  and  Analysis  project  [Visone,  2005],  for  example,  contains  modules  for  inferring  line-of-fire  information  from 
terrain  data  (you  can’t  shoot  from  A  to  B  if  there  is  a  mountain  in  the  way),  and  the  effects  of  weather  on  the  navigability  of 
terrain  (a  model  predicts  whether  certain  vehicles  can  pass  over  land  given  a  set  of  parameters  describing  the  recent  weather). 

Similarly,  the  notion  of  cover  or  concealment  involves  the  inability  for  something  to  be  seen  by  something  else  at  a  particular 
perspective.  It  is  a  relative  notion.  Something  that  serves  as  cover  or  concealment  to  observers  in  a  plane  (e.g.  dense  foliage) 
may  not  serve  as  cover  or  concealment  to  observers  at  the  same  level. 

6.  Troops 

For  friendly  forces,  it  must  be  possible  to  represent  the  equipment  and  weaponry  available,  maintenance  requirements,  and 
fuel  supplies.  Readiness  for  the  mission  considers  experience,  morale,  rest,  and  training.  Capabilities  include  the  mobility 
(based  primarily  on  the  equipment,  maintenance,  and  fuel  supplies),  and  intelligence  and  surveillance  assets 

In  JC3IEDM,  Troops  are  represented  as  an  Organisation  or  Unit.  Any  instance  of  ORGANISATION  may  have  an 
ORGANISATION-STRUCTURE  for  which  ORGANISATION-STRUCTURE-DETAIL  identifies  all  instances  of  OBJECT- 
ITEM-ASSOCIATION  that  pertain  to  the  specific  instance  of  ORGANISATION-STRUCTURE.  ORGANISATIONS  have 
associated  CAPABILITIES  and  STATUSES  as  well  as  LOCATIONS.  UNITS  have  associated  EQUIPMENT  and 


8  CityGML  is  an  XML  schema  based  extension  of  GML  to  urban  environments,  including  city  furniture  (lights,  etc).  It 
supports  various  increasingly  detailed  levels  of  description  up  to  the  description  of  building  interiors. 
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MATERIEL.  JC3IEDM  allows  for  the  representation  of  nearly  every  aspect  of  Troop  METT-TC  information  required 
except  those  deficiencies  noted  under  Enemy. 

JC3IEDM  does  not  allow  the  representation  of  the  current  formation  (e.g.  Column)  of  a  Unit,  unlike  in  MSDL. 

7.  Time 

It  must  be  possible  to  represent  the  time  available  for  any  military  operation.  It  must  also  be  possible  to  represent  the 
temporal  relations  between  events  and  actions  in  the  battlespace,  as  well  as  associating  reports  with  times. 

JC3IEDM  has  a  somewhat  parallel  temporal  structure  equivalent  to  its  geographical  or  location  structure.  Thus,  just  as  every 
object  can  be  assigned  a  location  in  JC3IEDM  via  an  OBJECT-ITEM-LOCATION,  every  action  can  be  associated  with  a 
temporal  interval  via  a  parameter  of  an  associated  ACTION-TASK.  Further,  each  report  has  an  obligatory  report  time. 
Again,  unlike  with  Location,  events  can  be  used  to  locate  other  events  temporally  through  ACTION-TEMPORAL- 
ASSOCIATION.  For  example,  it  is  possible  to  say  that  such-and-such  occurred  after  the  bombing  of  such-and-such  facility. 
However,  only  specific  events  can  be  explicitly  represented  as  being  correlated  in  this  way:  one  could  not  say  that  certain 
kinds  of  activities  increased  after  a  bombing  on  a  certain  date. 

Additionally,  it  is  not  possible  to  associate  artifacts  with  temporal  periods  in  JC3IEDM  only  with  specific  temporal  intervals. 
Thus,  one  cannot  say  that  a  particular  structure  is  a  Bronze  Age  structure  or  dates  to  Roman  occupation  of  that  area;  time 
intervals  with  definite  start  and  end  dates  are  required,  while  these  may  be  rather  fizzy  for  the  temporal  periods  at  issue. 

8.  Civil  Considerations 

It  must  be  possible  to  represent  the  influence  of  manmade  infrastructure,  civilian  institutions,  and  attitudes  and  activities  of 
the  civilian  leaders,  populations,  and  organizations  within  an  area  of  operations  on  the  conduct  of  military  operations.  Civil 
considerations  comprise  six  characteristics: 

•  Areas 

•  Structures 

•  Capabilities 

•  Organizations 

•  People 

•  Events 

Civil  Considerations  involve  representing  and  paying  proper  consideration  to  local  Areas,  Structures,  Capabilities, 
Organizations,  People  and  Events.  In  JC3IEDM,  Areas  are  represented  as  Locations,  Structures  as  Facilities,  Capabilities  as 
Capabilities,  and  Organizations  as  Group-Organizations. 

In  order  to  represent  the  presence  of  a  group  of  72  healthy  non-combatant  civilians  of  various  ages  on  the  roof  of  a  particular 
US  consulate  in  JC3IEDM,  one  would  say  the  following: 


<OWL> 

<OBJECT-ITEM  rdf:id="Gl"> 

<is-associated-with> 

<OBJECT- ITEM-GROUP- ACCOUNT> 

<ob j ect-item-group-acccount-id  rdf : resource="GA57"/> 
<is-referenced-to  rdf : resource="RPTD2"/> 
</OBJECT-ITEM-GROUP-ACCOUNT> 

</ is-associated-with> 

<is-geometrically-def ined-by> 

<!--  Let's  suppose  this  is  the  US  Consulate  --> 

<LOCATION  rdf : resource="L58"/> 

</ is-geometrically-def ined-by> 

</ OBJECT-ITEM> 

<OBJECT- ITEM-GROUP- ACCOUNT  rdf : id="GA57 "> 

<name-text>Group  of  US  Civilians  on  US  consulate  roof</name-text> 
<action-ref >ACT1</ action-ref> 

<count>72</ count> 

<is-the-count-of > 
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< PERSON- TYPE  rdf : id=" PT57 "> 

<person-type-category-code>CIV</person-type-category-code> 

<person-type-subcategory-code>NKN</person-type-subcategory-code> 

<has> 

<!--  A  specification  of  a  country  or  political  entity  to  which  membership  or 
allegiance  may  be  ascribed.  --> 

<AFFILIATION-GEOPOLITICAL  rdf : id="USA"> 

<af f iliation-geopolitical-code>USA</ af f iliation-geopolitical-code> 
</AFFILIATION-GEOPOLITICAL> 

</has> 

</ PERSON- TYPE> 

</ is-the-count-of > 

<qualif ier-code>HEALTH</ qualif ier-code> 

<is -enumerated- in> 

<OBJECT- ITEM-GROUP- ACCOUNT -DETAILS  rdf : id="GAD57 "> 

<provides-categorization-f or> 

<GROUP-CHARACTERI STIC  rdf : id="GC57 "> 

<age -group- code>MXD</ age -group- code> 

<GroupCharacteristic> 

</provides-categorization-f or> 

</ OB JECT- ITEM-GROUP- ACCOUNT -DETAILS > 

</ is-enumerated-in> 

</OBJECT-ITEM-GROUP-ACCOUNT> 

</ OWL> 


Notice  that  the  count  parameter  is  more  precise  than  it  might  be  reasonable  to  expect  from  a  report:  72,  not  “between  50  and 
100”  or  something  else. 

Every  area  (area  of  interest),  structure,  organization,  and  person  can  be  associated  with  an  ethnic,  linguistic,  political  and 
religious  affiliation.  However,  it  is  not  possible  to  provide  more  specificity  than  that  encoded  in  JC3IEDM  affiliation  codes. 
Thus,  it  is  not  possible  to  provide  finer-grained  affiliations  of  structures,  areas,  persons  or  groups  with  loyalties  to  particular 
leaders,  tribes,  sects  or  dialects  than  JC3IEDM  produces.  Category  codes  such  as  these  cannot  be  extended  via  the 
mechanism  of  OB  JECT -ITEM/OB  JECT -TYPE  discussed  earlier. 

The  ACTION -EVENT  entity  seems  mostly  to  have  been  envisioned  as  a  way  of  encoding  singular  events.  There  is  no 
concept  within  JC3IEDM  of  a  recurring  event  type  (such  as  a  religious  or  civil  holiday).  Thus,  there  is  no  way  to  represent 
such  recurring  event  types  in  JC3IEDM. 

9.  Negation  in  JC3IEDM 

It  is  not  possible  to  report  negative  facts  in  JC3IEDM.  One  cannot  directly  encode  the  statement  that  an  event  of  a  particular 
type  did  not  occur;  for  example,  that  the  (anticipated)  invasion  of  a  city  by  the  enemy  did  not  take  place.  At  most,  one  can 
report  the  current  state  of  the  situation  at  issue,  if  this  corresponds  to  the  negation  of  the  issue  at  hand.  For  example,  one 
cannot  say  that  a  bridge  was  not  destroyed.  One  can  report,  however,  that  the  bridge  is  still  standing.  One  cannot  report  that 
a  hospital  has  not  been  evacuated.  One  can  report  that  the  number  of  patients  is  some  non-zero  number.  When  no  such 
representation  of  the  current  state  is  possible  (as  with  being  non-invaded),  the  representation  of  negative  facts  is  not  possible. 

On  the  other  hand,  it  is  possible  to  indirectly  record  a  negative  fact  in  JC3IEDM  as  a  negative  response  to  a  REQUEST.  So, 
one  could  record  that  the  response  to  a  request  (did  the  enemy  invade  such-and-such  location  before  time  t?)  is  ‘No’.  This 
makes  reasoning  within  a  logical  representation  derived  from  JC3IEDM  more  complicated  than  that  envisioned  in  most 
automated  reasoning  systems. 

10.  Conclusion 

Military  applications  making  use  of  background  information  are  increasingly  converging  on  the  JC3IEDM  data  model  as  the 
basis  of  representing  military  situations.  Reasoning  about  the  impact  of  background  conditions  on  military  command  and 
control  would  require  the  translation  of  JC3IEDM  (or  a  successor)  into  a  logical  representation.  An  automated  translation  of 
JC3IEDM  into  a  suitable  logical  representation  that  correctly  represents  the  underlying  semantics  seems  to  be  possible. 
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However,  much  of  the  data  representing  background  battlespace  information  is  derived  from  M&S  technologies  that  are 
concerned  with  representing  data  in  two-dimensional  formats.  As  a  result,  much  of  the  data  assigns  properties  to  lines, 
points,  and  areas  on  a  map,  but  it  does  not  represent  all  of  the  facts  that  it  would  be  necessary  to  reason  about  symbolically. 
For  example,  shape  fde  data  may  tell  us  that  a  road  consists  of  a  line  connecting  various  points,  but  it  is  necessary  to  abstract 
from  this  that  the  road  connects  two  cities.  Performing  these  kinds  of  data  abstractions  will  be  necessary  for  doing  adequate 
reasoning  about  the  effects  of  METT-TC  factors  on  the  interpretation  of  battlespace  reports. 

Finally,  on  the  negative  side,  JC3IEDM  lacks  certain  depths  of  vocabulary  that  other,  more  specific  models  have.  For 
example,  it  does  not  provide  as  detailed  a  representation  of  as  many  geographic  or  built  features  as  the  US  Army’s  Terrain 
Common  Data  Model  (TCDM)  or  CityGML.  In  a  logical  framework  like  OWL,  this  could  be  remedied  by  simply  extending 
the  vocabulary  through  appropriate  namespaces.  But,  more  seriously,  given  its  origins  as  a  relational  data  model,  it  is  not 
surprising  that  it  is  unclear  how  to  represent  certain  things  in  JC3IEDM  that  would  require  quantification  over  events  or 
conditional  relationships  between  events.  These  include  the  representation  of  doctrines  as  quantifying  over  events  (for 
example,  that  always  or  in  most  cases,  if  the  enemy  is  doing  such-and-such,  they  will  do  thus-and-so).  At  best,  it  would  be 
possible  to  represent  such  information  within  JC3IEDM  currently  only  as  text  strings  that  are  immune  to  automatic 
reasoning.  It  would  be  necessary  to  embed  an  OWL  translation  of  JC3IEDM  within  a  modal  logic  to  reason  about  these. 
Similarly,  it  is  not  clear  how  to  represent  conditional  relationships  such  as  ‘dead  zones’  (if  Unit  U  is  positioned  here,  it 
cannot  fire  on  Location  L),  nor  conditional  vulnerabilities  (if  Enemy  Unit  EU  is  attacked  at  location  L,  it  will  not  be 
vulnerable  to/unable  to  do  XYZ). 

These  logical  shortcomings,  not  merely  the  lack  of  certain  vocabulary  items,  represent  a  more  serious  issue  with  respect  to 
the  usability  of  JC3IEDM  or  a  successor  within  a  system  for  automatically  reasoning  about  background  information  with  a 
shared  semantics. 
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